Are you planning to attend an interview for the Oracle Performance Tuning role but confused on how to crack that interview and also what would be the most probable Oracle Performance Tuning Interview Questions that the interviewer may ask? Well, you have reached the right place. Tekslate has collected the most frequently asked Oracle Performance Tuning Interview Questions which are often asked in multiple interviews.
Ans: In Proactive Tuning, the application designers can then determine which combination of system resources and available Oracle features best meet the needs during design and development. In reactive tuning, the bottom-up approach is used to find and fix the bottlenecks. The goal is to make Oracle run faster.
Ans: System-level tuning involves the following steps:
The optimizer can study the distribution of data by collecting and storing optimizer statistics. This enables intelligent execution plans. Choice of db_block_size, db_cache_size, and OS parameters (db_file_multiblock_read_count, cpu_count, &c), can influence SQL performance. Tuning SQL Access workload with physical indexes and materialized views.
|
Want to acquire industry skills and gain complete knowledge of Oracle Performance Tuning? Enroll in Instructor-Led live Oracle Performance Tuning Training to become Job Ready! |
Ans: The steps involved in database design level tuning are:
Determination of the data needed by an application (what relations are important, their attributes and structuring the data to meet the performance goals best)
Analysis of data followed by normalization to eliminate data redundancy.
Avoiding data contention.
Localizing access to the data to the partition, process and instance levels.
Using synchronization points in Oracle Parallel Server.
Implementation of 8i enhancements that can help avoid contention are:
Ans: Oracle decides how to retrieve the necessary data whenever a valid SQL training Hyderabad statement is processed.This decision can be made using one of two methods:
Rule-Based Optimizer
If the server has no internal statistics relating to the objects referenced by the statement, then the RBO method is used. This method will be deprecated in the future releases of Oracle.
Cost-Based Optimizer
The CBO method is used if internal statistics are present. The CBO checks several possible execution plans and selects the one with the lowest cost based on the system resources.
Ans: Object data types are user-defined data types. Both column and row can represent an object type. Object types instance can be stored in the database. Object datatypes make it easier to work with complex data, such as images, audio, and video. Object types provide higher-level ways to organize and access data in the database. The SQL attributes of Select into clause, i.e., SQL % Not found, SQL % found, SQL % Isoprene, SQL %Rowcount.
% Not found: True if no rows returned
E.g. If SQL%NOTFOUND then return some_value
% found: True if at least one or more rows returned
E.g. If SQL%FOUND then return some_value
%Isopen: True if the SQL cursor is open. It Will always be false, because the database opens and closes the implicit cursor used to retrieve the data
%Rowcount: Number of rows returned. Equals 0 if no rows were found (but the exception is raised) and a 1, if one or more rows are found (if more than one an exception is raised).
Ans: Translate: translate function replaces a sequence of characters in a string with another set of characters. The replacement is done single character at a time.
Syntax: translate( string1, string_to_replace, replacement_string )
Example: translate ('1tech23', '123', '456);
Decode: The DECODE function compares one expression to one or more other expressions and, when the base expression is equal to a search expression, it returns the corresponding result expression; or, when no match is found, returns the default expression when it is specified, or NA when it is not.
Syntax: DECODE (expr , search, result [, search , result]... [, default])
Example: SELECT employee_name, decode(employee_id, 10000, ‘tom’, 10001, ‘peter’, 10002, ‘jack’ 'Gateway') result FROM employee
| Related Article: Oracle Applications Tutorials |
Ans: A query that uses values from the outer query is called a correlated subquery. The subquery is executed once and uses the results of all the evaluations in the outer query.
Example: Here, the subquery references the employee_id in the outer query. The value of the employee_id changes by the row of the outer query, so the database must rerun the subquery for each row comparison. The outer query knows nothing about the inner query accept its results.
Ans:
UNION: The UNION operator is used to combine the result-set of two or more SELECT statements Tables of both the select statement must have the same number of columns with similar data types. It eliminates duplicates.
Syntax: SELECT column_name(s) FROM table_name1 UNION SELECT column_name(s) FROM table_name2
Example: SELECT emp_Name FROM Employees_india UNION SELECT emp_Name FROM Employees_USA
INTERSECT allows combining results of two or more select queries. If a record exists in one query and not on the other, it will be omitted from the INTERSECT results.
Ans: Open_form opens the indicated form. Call_form not just opens the indicated form, but also keeps the parent form alive. When new_form is called, the new indicted form is opened, and the old one is exited by releasing the memory. The new form is run using the same Run form options as the parent form.
Ans: Both “DB file sequential read” and “DB file scattered read” events signify the time waited for I/O read requests to complete. Time is reported in 100’s of a second for Oracle 8i releases and below, and 1000’s of a second for Oracle 9i and above. Most people confuse these events with each other as they think of how data is read from the disk. Instead, they should think of how data is read into the SGA buffer cache.
DB file sequential read:
A sequential read operation reads data into contiguous memory (usually a single-block read with p3=1, but can be multiple blocks). Single block I/Os are usually the result of using indexes. This event is also used for rebuilding the control file and reading datafile headers (P2=1). In general, this event is indicative of disk contention on index reads.
DB file scattered read:
Similar to DB file sequential reads, except that the session is reading multiple data blocks and scatters them into different discontinuous buffers in the SGA. This statistic is NORMALLY indicating disk contention on full table scans. Rarely, data from full table scans could be fitted into a contiguous buffer area; these waits would then show up as sequential reads instead of scattered reads.
The following query shows the average wait time for sequential versus scattered reads:
Ans: Oracle includes many performance tuning enhancements like:
Ans: Ensure that users don't have the SYSTEM tablespace as their TEMPORARY or DEFAULT tablespace assignment by checking the DBA_USERS view.
Ans: Poor data dictionary or library cache hit ratios, getting error ORA-04031. Another indication is steadily decreasing performance with all other tuning parameters the same.
Ans: When you get excessive contention for the copy latches as shown by the "redo copy" latch hit ratio. You can increase copy latches via the initialization parameter LOG_SIMULTANEOUS_COPIES to twice the number of CPUs on your system.
Ans: Rollback segments and associated structures.
Ans: The SMON process won't automatically coalesce its free space fragments.
[Check Out: Oracle DBA Tutorials]
Ans: If a select against the dba_free_space table shows that the count of a tablespaces extents is greater than the count of its data files, then it is fragmented.
Ans: One of the biggest responsibilities of a DBA is to ensure that the Oracle database is tuned properly. The Oracle RDBMS is highly tunable and allows the database to be monitored and adjusted to increase its performance.
One should do performance tuning for the following reasons:
Ans: One should implement a monitoring system to constantly monitor the following aspects of a database. Writing custom scripts, implementing Oracle’s Enterprise Manager, or buying a third-party monitoring product can achieve this. If an alarm is triggered, the system should automatically notify the DBA (e-mail, page, etc.) to take appropriate action.
Infrastructure availability:
Things that can cause service outages:
Things that can cause bad performance:
See question “What tuning indicators can one use?”.
Ans: Consider the following areas for tuning. The order in which steps are listed needs to be maintained to prevent tuning side effects. For example, it is no good increasing the buffer cache if you can reduce I/O by rewriting a SQL statement.
Database Design (if it’s not too late):
Poor system performance usually results from a poor database design. One should generally normalize to the 3NF. Selective denormalization can provide valuable performance improvements. When designing, always keep the “data access path” in mind. Also look at proper data partitioning, data replication, aggregation tables for decision support systems, etc.
Application Tuning:
Experience showed that approximately 80% of all Oracle system performance problems are resolved by coding optimal SQL. Also consider proper scheduling of batch tasks after peak working hours.
Memory Tuning:
Properly size your database buffers (shared pool, buffer cache, log buffer, etc) by looking at your buffer hit ratios. Pin large objects into memory to prevent frequent reloads.
Disk I/O Tuning:
Database files need to be properly sized and placed to provide maximum disk subsystem throughput. Also look for frequent disk sorts, full table scans, missing indexes, row chaining, data fragmentation, etc.
Eliminate Database Contention:
Study database locks latches and wait for events carefully and eliminate where possible.
Tune the Operating System:
Monitor and tune operating system CPU, I/O and memory utilization. For more information, read the related Oracle FAQ dealing with your specific operating system.
Ans: The following high-level tuning indicators can be used to establish if a database is performing optimally or not:
Buffer Cache Hit Ratio
Formula: Hit Ratio = (Logical Reads – Physical Reads) / Logical Reads
Action: Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i) to increase the hit ratio
Library Cache Hit Ratio
Action: Increase the SHARED_POOL_SIZE to increase the hit ratio
Ans: Oracle provide the following tools/ utilities to assist with performance monitoring and tuning:
Ans: Statspack is a set of performance monitoring and reporting utilities provided by Oracle from Oracle8i and above. Statspack provides improved BSTAT/ESTAT functionality, though the old BSTAT/ESTAT scripts are still available. For more information about STATSPACK, read the documentation in file $ORACLE_HOME/rdbms/admin/spdoc.txt.
Install Statspack:
cd $ORACLE_HOME/rdbms/admin sqlplus “/ as sysdba” @spdrop.sql — Install Statspack – sqlplus “/ as sysdba” @spcreate.sql– Enter tablespace names when prompted
Use Statspack:
sqlplus perfstat/perfstat exec statspack.snap; — Take a performance snapshots exec statspack.snap;
Get a list of snapshots:
select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT; @spreport.sql — Enter two snapshot id’s for different report
Other Statspack Scripts:
| sppurge.sql | Purge a range of Snapshot Id’s between the specified begin and end Snap Id’s |
| spauto.sql | Schedule a dbms_job to automate the collection of STATPACK statistics |
| spcreate.sql | Installs the STATSPACK user, tables and package on a database (Run as SYS) |
| spdrop.sql | Deinstall STATSPACK from database (Run as SYS) |
| sppurge.sql | Delete a range of Snapshot Id’s from the database |
| spreport.sql | Report on differences between values recorded in two snapshots |
| sptrunc.sql | Truncates all data in Statspack tables |
Ans: It’s important to have statistics on all tables for the CBO (Cost Based Optimizer) to work correctly. If one table involved in a statement does not have statistics, Oracle has to revert to rule-based optimization for that statement. So you really want for all tables to have statistics right away; it won’t help much to just have the larger tables analyzed.
Generally, the CBO can change the execution plan when you:
Ans: It is possible to improve %XYZ% queries by forcing the optimizer to scan all the entries from the index instead of the table. This can be done by specifying hints.
If the index is physically smaller than the table (which is usually the case) it will take less time to scan the entire index than to scan the entire table.
Ans: The UTLESTAT report shows I/O per tablespace but one cannot see what tables in the tablespace has the most I/O.
The $ORACLE_HOME/rdbms/admin/catio.sql script creates a sample_io procedure and table to gather the required information.
After executing the procedure, one can do a simple SELECT * FROM io_per_object; to extract the required information.
Ans: The likely cause of this is because the execution plan has changed. Generate a current explain plan of the offending query and compare it to a previous one that was taken when the query was performing well. Usually the previous plan is not available.
Some factors that can cause a plan to change are:
Ans: This problem normally only arises when the query plan is being generated by the Cost Based Optimizer. The usual cause is because the CBO calculates that executing a Full Table Scan would be faster than accessing the table via the index. Fundamental things that can be checked are:
USER_TAB_COLUMNS.NUM_DISTINCT – This column defines the number of distinct values the column holds.
USER_TABLES.NUM_ROWS – If NUM_DISTINCT = NUM_ROWS then using an index would be preferable to doing a FULL TABLE SCAN. As the NUM_DISTINCT decreases, the cost of using an index increase thereby is making the index less desirable.
USER_INDEXES.CLUSTERING_FACTOR – This defines how ordered the rows are in the index. If CLUSTERING_FACTOR approaches the number of blocks in the table, the rows are ordered. If it approaches the number of rows in the table, the rows are randomly ordered. In such a case, it is unlikely that index entries in the same leaf block will point to rows in the same data blocks.
Decrease the INIT.ORA parameter DB_FILE_MULTIBLOCK_READ_COUNT – A higher value will make the cost of a FULL TABLE SCAN cheaper.
Remember that you MUST supply the leading column of an index, for the index to be used (unless you use a FAST FULL SCAN or SKIP SCANNING).
Many other factors affect the cost, but sometimes the above can help to show why the CBO is not using an index. If from checking the above you still feel that the query should be using an index, try specifying an index hint. Obtain an explain plan of the query either using TKPROF with TIMED_STATISTICS, so that one can see the CPU utilization, or with AUTOTRACE to see the statistics. Compare this to the explain plan when not using an index.
Ans: You can run the ‘ANALYZE INDEX VALIDATE STRUCTURE’ command on the affected indexes – each invocation of this command creates a single row in the INDEX_STATS view. This row is overwritten by the next ANALYZE INDEX command, so copy the contents of the view into a local table after each ANALYZE. The ‘badness’ of the index can then be judged by the ratio of ‘DEL_LF_ROWS’ to ‘LF_ROWS’.
Ans: Some wait events from V$SESSION_WAIT and V$SYSTEM_EVENT views:
Event Name: Tuning Recommendation:
You liked the article?
Like: 1
Vote for difficulty
Current difficulty (Avg): Medium
TekSlate is the best online training provider in delivering world-class IT skills to individuals and corporates from all parts of the globe. We are proven experts in accumulating every need of an IT skills upgrade aspirant and have delivered excellent services. We aim to bring you all the essentials to learn and master new technologies in the market with our articles, blogs, and videos. Build your career success with us, enhancing most in-demand skills in the market.
